EV3 USB hacks #2356

dlech · 2026-01-04T21:22:23Z

Add a number of hacks to work around issues seen when flashing firmware on the EV3.

See individual commit messages for details.

Alternate to #2352.

The first patch on it's own should allow firmware flashing to complete without error (only warnings).

The rest of the patches aim to avoid triggering the warnings in the first place.

dlech · 2026-01-04T22:42:52Z

src/firmware/sagas.ts

+    // 384 bytes (triggered by 65536 % 1018 = 384). To work around this, we
+    // always erase two sectors to make the last chunk be twice as big
+    // (131072 % 1018 = 768).
+    const eraseSize = sectorSize * 2; // flash memory sector size


Suggested change

const eraseSize = sectorSize * 2; // flash memory sector size

const eraseSize = sectorSize * 2;

jaguilar · 2026-01-05T03:38:10Z

Affirmed that with 5ed3861, I can successfully flash the EV3 from my Windows computer.

laurensvalk · 2026-01-05T08:57:00Z

Thanks! This seems to be working, although I'm seeing a separate HID detection issue. I'll defer that to a separate issue.

I noticed that the progress bar doesn't appear until after a few seconds when it hits 8%, so for a little while you're left wondering if anything happened. It would be nice to start at 0%.

When I put in a dedicated progress at the start, there seems to be a separate bug that if progress is 0 it won't show the percentage. It just shows progress:

laurensvalk · 2026-01-05T09:03:35Z

function computeEv3ExtraLength(firmwareLength: number): number {
    // HACK: If the EV3 firmware size is not a multiple of 2 * 64KiB, then we
    // need to add some padding to avoid possibly triggering a bug where small
    // download payloads can cause bad replies. This is done by ensuring that
    // the last chunk is 1018 bytes.

    const maxChunkSize = 1018;
    const eraseSize = 2 * 64 * 1024;
    const remainder = firmwareLength % eraseSize;

    if (remainder === 0) {
        // Adding padding would cause an entire extra erase to be needed. Don't
        // do that and rely on a a different workaround (always erasing two sectors).
        return 0;
    }

    return maxChunkSize - (remainder % maxChunkSize);
}

Would things be a lot simpler if we write in chunks of 512 bytes?

dlech · 2026-01-05T14:49:43Z

I noticed that the progress bar doesn't appear until after a few seconds when it hits 8%, so for a little while you're left wondering if anything happened. It would be nice to start at 0%.

Yes, we never had such a slow first step on other hubs, so could use some work.

Would things be a lot simpler if we write in chunks of 512 bytes?

I tried that, but we get no response from the EV3 if the chunk size is anything other than 1018 (other than the last chunk).

laurensvalk · 2026-01-05T15:11:35Z

Ah, makes sense now. Thanks!

src/firmware/sagas.ts

laurensvalk · 2026-01-23T12:37:47Z

Since this is titled EV3 USB hacks, I've added two more. I propose to include this PR in the next beta/labs build to see where things stand. We can restore the USB reset if we find that we need to.

Add a hack to not fail if the EV3 bootloader sends an echo of the request instead of the expected response. There is a known compatibility issue with the EV3 bootloader USB and, e.g. Windows with USB 3.0 ports. This apparently causes a race condition where commands that don't take long to process before sending a response will have the request echoed back instead of receiving the actual response. If this happens, we can ignore it and assume the command was successful. It just won't work, e.g. for the version command since that has a payload in the response.

Change from erasing 1 sector at a time to erasing 2 sectors at a time. This works around a USB issue where commands that don't take long to execute can receive an incorrect response. The point of erasing 2 sectors at a time is that when we write the data to the sectors that we just erased, the last (partial) chunk of data is now twice as large, which makes it take twice as long to write. This seems to be long enough to avoid the USB issue.

Add an extra progress between erasing and writing. This makes the progress not stall for quite as long before progressing when flashing smaller firmwares.

Add a function to pad EV3 firmware size to avoid potentially triggering bugs in the EV3 bootloader. When we do a download command with too small of a payload, the bootloader can send a bad response. We can work around this by ensuring that the firmware size is such that the last chunk is the maximum size. This way we never send a small chunk that could trigger the bug.

dlech · 2026-01-23T15:18:36Z

src/usb/sagas.ts

    if (hotPlugDevice !== undefined) {
        yield* put(usbHotPlugConnectPybricks());
+
+        // Even though we get the connect event, the browser does not


Does this only apply to Linux?

We should test on a slow machine like a Raspberry Pi to make sure the delay is long enough.

And we should report this as a bug to Chromium. Then it could be fixed in a reliable way. For example, it could be that they are using the udev add event instead of bind that triggers the event before udev rules have run instead of after.

I'm going to drop the delay commit since I think we an do it in a more robust way (assuming there is a specific error we can handle). What is the actual error that you are getting?

Apparently I already answered my own question last October. pybricks/support#2372 (comment)

dlech · 2026-01-23T15:20:27Z

src/usb/sagas.ts


    exitStack.push(() => usbDevice.close().catch(console.debug));

-    // Always reset the USB device to ensure it is in a known state.


Since we already have a good idea of what the solution will be to replace this, I think we should go ahead and implement it now instead of doing a buggy release.

I don't currently know what the solution is, but I'm happy to wait if you think we have one.

I've not been able to reproduce any issues without the reset so far.

dlech · 2026-01-23T15:22:29Z

src/usb/sagas.ts

        // if there is exactly one Pybricks device connected, we can connect to
        // it, otherwise we should let the user choose which one to connect to
        if (pybricksDevices.length === 1) {
+            // REVISIT: Device is passed as hotplug device, even though it is


I don't understand what needs to be revisited here. Is the problem just the technicality in the naming?

No. This is not a hotplug. This gets called when you load the page and the hub is already connected. So we don't need the hotplug delay (but it doesn't hurt to keep).

It could be (very unlikely but still possible) that the USB was plugged in at the same time the page was loaded, so probably best to keep it and not differentiate.

This operation does not work on Windows, and does not appear to be crucial on other platforms either. The browser seems to already handle resetting the endpoints as needed when connecting or closing the browser (at least on Linux)

dlech · 2026-01-24T22:14:11Z

I know we still need the delay, but I think there is some room for improvement on that patch, so I'm going to go ahead and merge this and we can start a new PR for the delay.

This was referenced Jan 4, 2026

[Bug] EV3 firmware installation sends bad status values pybricks/support#2375

Closed

feat(flash): Switch to sector-by-sector flashing c4ev3/ev3duder#47

Open

dlech commented Jan 4, 2026

View reviewed changes

dlech force-pushed the dlech branch from 72854cf to 5ed3861 Compare January 4, 2026 23:27

laurensvalk reviewed Jan 23, 2026

View reviewed changes

src/firmware/sagas.ts Show resolved Hide resolved

laurensvalk force-pushed the dlech branch from 5ed3861 to 3eaabc4 Compare January 23, 2026 12:35

dlech added 4 commits January 23, 2026 14:21

firmware/ev3: add extra progress report

e001642

Add an extra progress between erasing and writing. This makes the progress not stall for quite as long before progressing when flashing smaller firmwares.

laurensvalk force-pushed the dlech branch 2 times, most recently from f751d1f to fcb0286 Compare January 23, 2026 13:32

dlech commented Jan 23, 2026

View reviewed changes

usb/sagas: Don't reset USB device.

a8004d0

This operation does not work on Windows, and does not appear to be crucial on other platforms either. The browser seems to already handle resetting the endpoints as needed when connecting or closing the browser (at least on Linux)

dlech force-pushed the dlech branch from fcb0286 to a8004d0 Compare January 24, 2026 22:11

dlech enabled auto-merge (rebase) January 24, 2026 22:12

dlech merged commit 3abc3f3 into master Jan 24, 2026
2 checks passed

dlech deleted the dlech branch January 24, 2026 22:16

	const eraseSize = sectorSize * 2; // flash memory sector size
	const eraseSize = sectorSize * 2;


		exitStack.push(() => usbDevice.close().catch(console.debug));

		// Always reset the USB device to ensure it is in a known state.

EV3 USB hacks #2356

EV3 USB hacks #2356

Uh oh!

Conversation

dlech commented Jan 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jaguilar commented Jan 5, 2026

Uh oh!

laurensvalk commented Jan 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laurensvalk commented Jan 5, 2026

Uh oh!

dlech commented Jan 5, 2026

Uh oh!

laurensvalk commented Jan 5, 2026

Uh oh!

Uh oh!

laurensvalk commented Jan 23, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlech Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlech Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dlech commented Jan 24, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dlech commented Jan 4, 2026 •

edited

Loading

laurensvalk commented Jan 5, 2026 •

edited

Loading

dlech Jan 24, 2026 •

edited

Loading

dlech Jan 23, 2026 •

edited

Loading